BizTalk Server 2009 : Identifying Standard Message Exchange Patterns (part 2) - One-way services

One-way services

This is your straightforward fire and forget pattern. The message is sent unidirectionally and asynchronously to a waiting receiver. If you grew up building components with fine-grained functional request/reply interfaces, this idea of throwing a message out of your application and not expecting anything back may seem a bit useless. However, this manner of service communication is a powerful way to build more event-driven applications and embrace non-blocking service invocation patterns. A one-way service interface may send a message to a single destination (a point-to-point solution), a defined list of recipients (multi-cast solution) or be a general broadcast (pub/sub solution). The key is, the caller remains unaware of the journey of the message once it is swallowed up by the service.

In scenarios where the sender and receiver may not both be online or active at the same time, a one-way service pattern offers a way to buffer this communication. For instance, I can build a service that offers an operation called PublishCustomerChange which takes a Customer entity possessing modified data attributes. The service itself may decide to queue up requests and only update the legacy Customer Management application during scheduled intervals throughout the day. However, the service may still receive requests all day, but because there is no expectation of a response to the submitter, the service can decide to prioritize the processing of the request until a more convenient time.

BizTalk Server 2009 is at its finest when working with one-way messaging patterns. Messages flow into the MessageBox and inherently cascade down to many places. When freed from the restraints of an expected service response, BizTalk Server can more powerfully chain together data and processes into far-reaching solutions. Consider a message sent to BizTalk via a one-way service interface. The loosely-coupled orchestrations and send ports can simply subscribe to this message's data, type, or attributes and act upon it. There is no concern for doing anything else but acting upon the data event. When a request/response receive port is designated as the service publisher, there can feasibly be only a single subscriber (and responder) to the request.